The device registry from commissioning to decommissioning, the telemetry plane — ingest, time-series store, live stream — alert evaluation and acknowledgement, the product & schema catalogs, and remote device commands for every frigo / koelkast unit in the field. A core subdomain: the monitored converged micro data center is the product.
The Devices service owns two stores with one boundary between them: the relational registry (Device, Alert) and the time-series plane outside Postgres. Devices ingest over mTLS directly — never through the BFFs or the user gateway — and only Alert rows cross into the relational model (SVC-9, the ⚠ the ERD records under PTL-1).
Reads from: Structure (SiteId) · Tenancy (CustomerId) · Coverage (the scope resolver for every partner read). Portal is the primary client; commissioning arrives from the won-deal saga.
The words this context uses — the same in code, conversation and spec.
Telemetry reading set (refrigeration schema). A device sample carries, at minimum: return-air, supply-air and ambient-air temperature (°C), relative humidity (%RH), power draw (kW) and cooling COP, plus the enclosure's door state for its front · back · side doors (open/close intervals) and the per-module rollup on multi-module units. The converged (Nevera) schema adds PUE, battery and bus voltage. This reading set is what the Portal's device-detail multi-metric time-series stack renders (PTL-1, SPEC-UIX-DEV §7.1); door-open beyond its threshold and out-of-band readings are what alert evaluation escalates. The exact per-family field set lives in the schema registry, not in this prose — this is the vocabulary, not the wire format.
The consistency boundaries — one root each, guarding its invariants in a single transaction; cross-aggregate ties are by identity.
How this context meets its neighbours, with the integration pattern named on each edge.
The deployment mapping: this context becomes the Devices service. Paths relative to api.riversync.com/v1, except the ingest plane; access notation per the master.
The past-tense facts this context publishes (and consumes) — its share of the platform's published language.
The modeling rules that bind this context — the master holds the full set; data integrity stays with the ERD drill-downs.
| Version | Date | Changes |
|---|---|---|
| 0.1 | 12 Jun 2026 | First draft — split proposed with SPEC-DDD v0.1 (as the Fleet domain) |
| 0.2 | 13 Jun 2026 | Renamed from Fleet — the service is now Devices & telemetry (SVC-DVC, /devices route prefix, SPEC-DDD-DVC); vocabulary change only, ownership and boundaries unchanged (SPEC-PRD v0.12) |
| 0.3 | 28 Jun 2026 | Reframed as a Domain-Driven Design context (with the set, SPEC-DDD v0.14) — leads with ubiquitous language & aggregates (Device, Alert, ProductFamily, TelemetrySchemaFamily) and the context relationships (customer/supplier to Support via alert.raised; consumes deal.won from Sales). Classified a core subdomain; the API is demoted to the physical view. No ownership change. |
| 0.4 | 2 Jul 2026 | Telemetry reading set documented (§2). Added the canonical refrigeration reading set — return / supply / ambient air, humidity, power, COP and per-door (front · back · side) door state — as the vocabulary the Portal's device-detail multi-metric stack renders (PTL-1, SPEC-UIX-DEV §7.1). Reflects the prototype's schema panes; wire format stays in the schema registry. No ownership or boundary change. |